home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-vaudreuil-mime-delivery-00.txt < prev    next >
Encoding:
Text File  |  1993-09-21  |  13.3 KB  |  343 lines
  1. Network Working Group                                 Greg Vaudreuil
  2. Internet Draft                                                 Tigon
  3. Expires 3/17/93                                   September 17, 1993
  4.  
  5.               Delivery Report Content-Type for use with MIME
  6.  
  7. 1.    Status of this Memo
  8.  
  9. This document is an Internet Draft.  Internet Drafts are working documents of
  10. the Internet Engineering Task Force (IETF), its Areas, and its Working
  11. Groups.  Note that other groups may also distribute working documents as
  12. Internet Drafts.
  13.  
  14. Internet Drafts are valid for a maximum of six months and may be updated,
  15. replaced, or obsoleted by other documents at any time.  It is inappropriate
  16. to use Internet Drafts as reference material or to cite them other than as a
  17. "work in progress".
  18.  
  19. 2.   Abstract 
  20.  
  21. The memo defines a MIME content type for the return of delivery reports,
  22. service availability, and receipt notifications.  This content type is
  23. intended to be machine processable while remaining human readable.
  24.  
  25. 3.   Introduction
  26.  
  27. The current Internet Mail protocol suite is lacking in several features
  28. necessary to the management of large mailing lists and for error processing
  29. on behalf of a user.  There is no standard error report format which would
  30. facilitate implementation of user friendly mail interfaces.  This content
  31. type defines a mechanism for delivery reports which is extensible for a range
  32. of system to user notification services such as read receipt delivery,
  33. positive delivery acknowledgment, and service non-availability notification.
  34.  
  35. 3.1. Non-Delivery Notification
  36.  
  37. The Internet currently provides for error reports, but in a non-standard and
  38. limited use format.  This specification is intended to replace these error
  39. reports with a more standard mechanism.  SMTP provides a standardized status
  40. reporting system in the use of numeric reply-codes but these are not
  41. generally made available in the error message mailed to the sender.  The SMTP
  42. error codes do not provide a complete diagnostic record and need to be
  43. extended for the purposes of delivery reports to include non-SMTP network and
  44. communications errors which may cause non-delivery.
  45.  
  46. 3.2. Positive Delivery Notification
  47.  
  48. The RFC822/MHS mapping standards identify a mechanism for requesting such a
  49. delivery notification and this specification provides a mechanism to return
  50. such a request.  For the purposes of the Delivery Notification, delivery will
  51. be considered completed when the message is delivered to the destination
  52. mailbox. 
  53.  
  54. 3.3  Read Receipt Notification
  55.  
  56. There is a mechanism specified in the RFC822/MHS documents for requesting a
  57. read receipt notification.  While the specific implementation of such a
  58. notification has been contentious, this specification provides a mechanism
  59. for sending such a notification if one is to be implemented.  The specific
  60. meaning of "read" varies by implementation environment and is left undefined.
  61.  
  62. 3.4  Service Notification
  63.  
  64. MIME allows the sending of mixed-media messages and in particular messages
  65. which are not text.  There is no specific mechanism for reporting to the
  66. sender when such a message is deliverable but not readable.  In many
  67. messaging environments, it may be useful to return a message to the sender
  68. indicating that the specified content-type is unsupported.  It is expected
  69. that this information will be cached, either informally by a human user, or
  70. by a local directory for use by the user agent.  Determination of what is a
  71. supported and what is an unsupported feature is an implementation issue
  72.  
  73. 4.   Delivery Report Framework
  74.  
  75. The delivery report mechanism is implemented by defining two new MIME
  76. content-types, Multipart/Delivery-Report and Application/Delivery-Report. 
  77. The multipart/delivery report is the syntactically the same as a
  78. multipart/mixed but contains exactly two parts, the first is the
  79. Application/Delivery-Report and the second is a return of content.  If return
  80. of content is not requested or supported, the Multipart/Delivery Report is
  81. not needed.
  82.  
  83. The Application/Delivery-Report contains the specific delivery information,
  84. such as error reports, read-receipts, and service notifications.  This
  85. content-type is formatted according to the Simple Text Interchange Format and
  86. contains information for machine processing of the message.  STIF Comments
  87. are permitted where appropriate for human consumption in the absence of an
  88. application capable of interpreting the error report.
  89.  
  90. 5.   Multipart/Delivery-Report
  91.  
  92. Mime type name: Multipart
  93. Mime Sub-Type name: Delivery-Report
  94. Required Parameters: Boundary
  95. Optional Parameters: None
  96. Encoding Considerations: Quoted-Printable and Base-64 are prohibited.
  97.  
  98. The syntax of a Multipart/Delivery-Report is identical to the Multipart\Mixed
  99. content type.  The Delivery Report always contains two body parts.  The first
  100. body part is an Application/Delivery-Report, defined in a subsequent section
  101. of this appendix.  The second body part may be of any content-type and
  102. contains the returned message for which the delivery report is defined. The
  103. returned comment will normally be a message/RFC822.
  104.  
  105. If an Application/Delivery-Report does not include returned content,
  106. Multipart/Delivery-Report should not be used.
  107.  
  108. 6.   Application/Delivery-Report
  109.  
  110. Mime type name: Application
  111. Mime Sub-Type name: Delivery-Report
  112. Required Parameters: None
  113. Optional Parameters: None
  114. Encoding Considerations: 7bit is always sufficient.
  115.  
  116. The Application/Delivery-Report body is designed to deliver delivery and
  117. non-delivery reports, read-receipts, and service notifications.  It is
  118. generally used with a Multipart/Delivery-Report when the original content is
  119. to be returned to the sender. 
  120.  
  121. The Application/Delivery Report is a series of attribute-value pairs
  122. formatted as RFC 822 headers.  While this body-part is designed to be machine
  123. parsable, US-ASCII comments are permitted in each line. 
  124.  
  125. Generation of error messages from this error report for user consumption
  126. should be based on the error code, not the explanatory text. Choice of an
  127. appropriate language and character set is independent of the error. The
  128. choice of US ASCII for the explanatory text is based on current practice and
  129. is expected to be obsoleted by nationalized user interfaces.
  130.  
  131.  
  132. 6.1. Required Attributes.
  133.  
  134. o    Message-ID: - message id of the message being reported on
  135.  
  136. o    Intended-Recipient - a coma separated list of one or more recipient
  137.      email addresses for which this report applies.
  138.  
  139. o    Delivery-Status - This field indicates whether further delivery attempts
  140.      will be made. (Finished, Continuing)
  141.  
  142. 6.2 Service Specific Attributes
  143.  
  144. o    Message-Delivered - Time of message delivery
  145.  
  146. o    Message-Not-Delivered - Time of failed attempt
  147.  
  148. o    MTA-Error-Code - Error code returned which caused delivery notification
  149.      to be returned. The set of error codes defined by the SMTP protocol is
  150.      extended to address general network errors.
  151.  
  152. o    Service-Not-Available - MIME content type of service not supported on
  153.      the destination mailbox.
  154.  
  155. o    Message-Read - Time message was read
  156.  
  157. 6.2. MTA Error Codes
  158.  
  159. The following non-delivery error codes are available from SNMP for direct
  160. peer-to-peer networking.
  161.  
  162. The 400 series of error codes are "soft" failures, indicating that re-try is
  163. reasonable at a later time.
  164.  
  165. 421  <domain> Service not available, [This may be a reply to any command if
  166.      the service knows it must shut down]
  167.  
  168. 450  Requested mail action not taken: mailbox unavailable [E.g., mailbox
  169.      busy]
  170.  
  171. 451  Requested action aborted: local error in processing
  172.  
  173. 452  Requested action not taken: insufficient system storage
  174.  
  175. The 500 series of error codes are "hard" failures, indicating that the
  176. message should be returned to the sender as undeliverable.  The listed
  177. commands are a subset of the full SNMP diagnostics.
  178.  
  179. 500  Syntax error, command unrecognized This may include errors such as
  180.      command line too long]
  181.  
  182. 501  Syntax error in parameters or arguments
  183.  
  184. 502  Command not implemented
  185.  
  186. 503  Bad sequence of commands
  187.  
  188. 504  Command parameter not implemented
  189.  
  190. 550  Requested action not taken: mailbox unavailable, mailbox not found, no
  191.      access
  192.  
  193. 551  User not local; please try <forward-path>
  194.  
  195. 552  requested mail action aborted: exceeded storage allocation
  196.  
  197. 553  Requested action not taken: mailbox name not allowed [E.g., mailbox
  198.      syntax incorrect]
  199.  
  200. 554  Transaction Failed
  201. 6.3. Network Error Codes
  202.  
  203. Often mail transfer failures result from network or transport level
  204. conditions which are not part of the SMTP protocol. These errors are
  205. generally made known in current error reports, but need to be assigned
  206. numeric codes to be used in the Application/Delivery-Report content type. A
  207. new series of error codes, 6XX is created to report on such failures.
  208.  
  209. 600  Host unreachable.  The network address of the host specified is not
  210.      connected to the MTA.
  211.  
  212. 610  Network Unreachable. The network the host resides upon is either not
  213.      connected to the MTA.
  214.  
  215. 620  Hostname does not exist.  A non existent destination was provided.
  216.  
  217. 630  Service not available. SMTP on TCP port 25 is not available.
  218.  
  219.  
  220. 7.   Return of Content
  221.  
  222. Return of content may be wasteful of network bandwidth and a variety of
  223. implementation strategies can be used.  Generally the sender should choose
  224. the appropriate strategy and inform the recipient of the required level of
  225. returned content required. This can be done with the RFC822/MHS header
  226. "return content".  The three values for this field are "none", "full", and
  227. "initial".  The default behavior in the absence of this header varies by
  228. application and should be set by the MTA.
  229.  
  230. Return of full content uses significant bandwidth but enables review and
  231. resending with a different addresses or formats.
  232.  
  233. Return of content can be provided with caching without using additional
  234. network bandwidth. Outgoing messages can be cached for a suitable period of
  235. time, and if a non-delivery, service notification, or read-receipt is
  236. received, it can be matched with the cached message and presented to the
  237. user.
  238.  
  239. Return of a partial message segment may be sent to remind the sender of the
  240. topic of the message.  This saves bandwidth compared with sending the full
  241. message, but may either not be enough of the message for context or be
  242. unsuitable for further processing. Handling of partial content is tricky in
  243. a mixed media environment.  Return of partial content may be useless for
  244. certain content-types.  Each content-type has a natural "unit" which should
  245. be respected in returning a partial content.  For example, a text message
  246. should include enough text to capture at least the first paragraph.  A fax
  247. content should include sufficient information to print the cover page.  A
  248. audio segment should contain enough data for several seconds of play time. 
  249. Each of these units varies in the number of bytes and cannot be implemented
  250. in a useful manner by arbitrary truncation.
  251.  
  252. It is recommended that a gateway return full or no content.  It should return
  253. partial content only if it has knowledge of how to truncate that content. 
  254. The following are recommended units for truncation.
  255.  
  256.  
  257. Multipart/*    Return first body part
  258.  
  259. Image/*        Return one page
  260.  
  261. Audio/*        Return 10 seconds
  262.  
  263. Text/*         Return 1 page
  264.  
  265. 8.   Example Delivery Reports
  266.  
  267. 8.1. Complete Non-Delivery Notification
  268.  
  269. The following error message was sent to the user 2145551212 on message
  270. machine HOST1.mycompany.com because the message addressed to 2145551234 does
  271. not exist on message machine HOST2.mycompany.com.  The error message was sent
  272. by the mail program itself and not on behalf of a particular user and
  273. therefor has the From: address of "Postmaster". Note that this is not
  274. relevant to the user.
  275.  
  276. To: 2145551212@host1.mycompany.com
  277. From: postmaster@host2.mycompany.com
  278. Mime-Version: 1.0
  279. Date: Mon, 3 Fri 93 13:39:31 PDT
  280. Message-ID: HOST2.mycompany.com-1212121212
  281. Content-type: Multipart/Delivery-Report; boundary =
  282.   "error-report-boundary"
  283.  
  284. --error-report-boundary
  285. content-type: Application/Delivery-Report
  286.  
  287. Message-Id: host1.mycompany.com-123456789
  288. Intended-recipient: 2145551234@host2.mycompany.com
  289. Delivery-Status: Finished
  290. Message-Not-Delivered: Fri, 3 Sep 93 13:39:31 PDT
  291. MTA-Error-Code: 550  (Invalid mailbox)
  292.  
  293. --error-report-boundary  
  294. Content-type: Audio/U-Law
  295. Content-Transfer-Encoding: Base64
  296.  
  297. glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
  298. dflksdlkfIasdrkfpWlqkw3okWlkgf9i345kWlfkg9iugp34k5poi09fg
  299. jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
  300. krQgi35oktWldkfbrpouqe5yklm2poTihcvxbQkmstyTi5ryToifnglkj
  301. dlkgpokpeowrit09IpokporkgwI==
  302.  
  303. --error-report-boundary--
  304. 8.2. Example Read Receipt Message
  305.  
  306. The following delivery report was sent to user 2145551212 on machine
  307. host1.mycompany.com after the message sent to 2145551234 on machine
  308. HOST2.mycompany.com was read.  No return of content was requested.
  309.  
  310. To: 2145551212@host1.mycompany.com
  311. From: 2145551234@host2.mycompany.com
  312. Message-ID: HOST2.mycompany.com-1212121212
  313. Mime-Version: 1.0
  314. Date: Mon, 3 Fri 93 13:39:31 PDT
  315. Content-type: Application/Delivery-Report
  316.  
  317. Message-Id: host1.mycompany.com-123456789
  318. Intended-recipient: 2145551234@host2.mycompany.com
  319. Delivery-Status:  Finished
  320. Message-Read: Fri, 3 Sep 93 13:39:31 PDT
  321.  
  322.  
  323. 9.   Security Considerations
  324.  
  325. Delivery notifications are only as secure as the mechanism by which they have
  326. been sent.  It is important to note that automatic deletion of an address
  327. from a mailing list based on delivery reports may provide a mechanism for
  328. denial-of-service attacks.
  329.  
  330. 10.  Authors Address
  331.  
  332. Gregory M. Vaudreuil
  333. Tigon Corporation
  334. 17060 Dallas Parkway
  335. Suite 109
  336. Dallas, Texas 75248-1905
  337. (214) 733 2722
  338. GregV@cnri.reston.va.us
  339.  
  340.  
  341.  
  342. 
  343.